This invention relates to voice-over-Internet-Protocol (VoIP) systems, and more particularly to adjustments of current bandwidth usage of VoIP channels on an unregulated network such as the Internet.
Traditional applications such as telephone calling can now use the Internet rather than traditional telephone networks. Voice-over-Internet-Protocol (VoIP) applications capture a user's voice, digitize and compress the voice, and transmit the coded voice as data inside Internet-protocol (IP) packets that can be sent over the Internet.
VoIP applications can be installed on personal computers (PC's), other devices connected to the Internet, or on translation servers such as Internet-to-Telephone gateways or Protocol Converters. Each party to a call runs a local copy or client of the VoIP application.
FIG. 1 is a diagram of a prior-art VoIP system experiencing packet loss. VOIP application 10 is operated by user A while VOIP application 12 is operated by user B at different nodes on the Internet. User A's speech is digitized, coded, compressed, and fitted into IP packets 20 by VOIP application 10. These IP packets 20 containing user A's voice are routed over the Internet to VOIP application 12.
VOIP application 12 receives these IP packets 20, extracts and de-compresses the voice data, and plays the voice as audio to user B. User B's voice is then captured, coded, compressed, and fitted into IP packets 22 by VOIP application 12. IP packets 22 containing user B's voice are also routed over the Internet back to VOIP application 10 for playback to user A, achieving a full-duplex voice call.
IP packets can be routed over a wide variety of paths using the Internet. Indeed, the de-centralized nature of the Internet allows routing decisions to be made at a number of points along the paths between applications 10, 12. The paths taken by packets 20 in the A-to-B direction can differ from the path taken by packets 22 in the reverse (B-to-A) direction. For example, packets 20 may pass through intermediate routers 14, 16, while packets 22 pass through router 18. Such non-symmetric routing can produce non-symmetric routing delays and challenges for the VOIP system.
Various network problems may occur. A router may temporarily fail, causing some packets to be delayed or lost entirely. The number of arriving packets may suddenly jump, producing congestion such as at router 18. Router 18 may delay packets 24 while the increased packet load occurs. Packets may continue to be delayed after the initial failure is fixed as the packet backlog is worked off. If the input buffers for router 18 overflow, packets 24 may be dropped or lost rather than simply delayed.
Bandwidth limitations may also occur. Packets may need to reach a user through a low-bandwidth dial-up modem line. Some types of modems such as satellite Internet Access or Asymmetric Digital-Subscriber Lines (ADSL) may have much more bandwidth in one direction (download) than in the other (upload). Occasional interference may further delay packets. The modem user may send email or browse a web site, reducing further the limited bandwidth available to the VOIP application's packets. Thus bandwidth limitations may be both permanent and temporary.
VOIP applications 10, 12 may have limited network status communicated between them. Sending VOIP application 12 may be unaware of packet routing problems on the packets it sends. The problems may not exist in packets received by VOIP application 12 from VOIP application 10, as the routing paths may not be symmetrical. Even on a symmetric network congestion or limitations on bandwidth may exist only in one direction, such as upload and download directions on a cable modem or ADSL.
VoIP application 10 cannot determine its outbound bandwidth simply by looking for delays of incoming packets received from VoIP application 12, since different routes may be taken by packets 20 sent and packets 22 received by application 10.
During initialization of a call between applications 10, 12, some provisioning may be performed to determine the initial bandwidths available between applications 10, 12. Such provisioning may be similar to fax machines that negotiate compression standards used and bandwidth or baud rate for each call. However, this initial provisioning is often not continuous. Changes to the Internet that later occur during the call are not detected once provisioning is over and the call is started.
FIG. 2A shows voice data that is packetized and transmitted. The user's voice can be captured as analog waves of varying frequencies that are digitized and coded. The coded voice data is divided into packets and transmitted. Sequence numbers are added to the packets to allow the packets to be re-ordered when some are delayed more than others. The sequence numbers thus allow for out-of-order reception and detection of missing packets. In this example the coded voice is divided into four packets, each packet containing coded voice data for an equal, fixed time period of 20 milli-seconds.
FIG. 2B shows packetized voice data received after varying network delays. The sequence numbers are used to re-order the packets when they arrive with varying network delays.
In this example, packet 2 is delayed slightly, causing a gap to occur between the end of playing the voice for packet 1, and the start of voice play for packet 2. A larger gap occurs between packets 2 and 3, between times S2 and S2′. These gaps may be filled in by interpolating voice data, or by adding silence. However, the pace of the user's voice may seem uneven or jerky due to such gaps.
Of course, all voice could be delayed by a large amount, such as 5 seconds, to allow for late packets. However, this requires a larger packet-input buffer and would greatly increase the delay or latency that the user hears. This delay may be noticeable to the user and annoying. Full-duplex conversation becomes impractical as the delay grows to several seconds. Thus the input buffer has a practical size limit, and packets cannot be delayed for too long. The quality of a full-duplex conversation is better when buffering and delays are kept as small as possible.
Such gaps caused by delayed packets can reduce the quality of the voice played. When a temporary interruption occurs along the path taken by the VoIP packets, packets may pile up in buffers near the point of interruption. Should service be quickly restored, the stored packets in the buffers may be sent after some delay. However, longer-duration interruptions can cause router buffers to overflow. Packets may then be dropped or discarded before reaching their destinations.
Once the interruption ends, the older packets are likely to be sent first by the router. Newer packets may be delayed even after the interruption ends as the backlog of packets is transmitted. Thus stale packets of older voice data may be delivered before more current voice data. These older packets may already be too old to be played, resulting in a lengthening of what was a brief moment of congestion.
Some VOIP systems may detect packet loss or a drop in voice quality. However, packet loss is not sufficiently sensitive to early stages of congestion, since congestion usually begins before packet loss occurs. Waiting to detect packet loss allows the congestion to become much worse before action is taken.
Congestion and Bandwidth Detection
Rather than simply wait for packet losses to mount up, the parent application detects such congestion beginning to occur. In addition to congestion estimates, bandwidth may also be estimated to detect when bandwidth is limited but packet loss is not yet occurring.
Congestion and bandwidth restrictions are detected by one VOIP application and sent to the other VOIP application. Each VOIP application monitors and estimates congestion and bandwidth on its inbound direction for use by the other VOIP application. Congestion and bandwidth estimates can be embedded in the VOIP packets for sending to the other VOIP application.
VOIP applications can respond to the congestion and bandwidth estimates in a variety of ways. The present application describes a closed-loop system wherein one VOIP application estimates congestion and bandwidth while the other VOIP application receives the bandwidth and congestion estimates and adjusts its packet flow to compensate.
What is desired is a VOIP application that can continuously receive estimates of network problems such as congestion, limited bandwidth, and delays. A VOIP system that can continuously respond to such estimates by adjusting audio-compression and bandwidth usage is desirable. A pair of VOIP applications that continuously monitor network conditions and adjust packet flow is desired. A closed-loop feedback VOIP system for network monitoring and audio-packet-flow adjustment is desired.